Modifying membership rights in a data exchange

ABSTRACT

Systems and methods for managing membership in a private data exchange are provided herein. In one embodiment, the method comprises adding a new member to a data exchange, wherein the data exchange comprises a set of listings, each listing comprising data from one or more datasets stored on a cloud computing service. An account type is assigned to the new member, the account type comprising at least one of a consumer type, provider type, or exchange administrator type. Each of the account types associated with one or more rights with respect to the set of listings, such that the new member has a set of rights based on the account type. The set of rights of the new member are then modified with respect to one or more listings from the set of listings based on a set of visibility and access rules for each of the set of listings.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.16/746,758, filed Jan. 17, 2020, entitled “MANAGING MEMBERSHIP IN APRIVATE DATA EXCHANGE,” which claims the benefit of U.S. ProvisionalApplication No. 62/899,571, filed Sep. 12, 2019, the entire contents ofwhich are incorporated by reference herein.

TECHNICAL FIELD

The present disclosure relates to resource management systems andmethods that manage data storage and computing resources.

BACKGROUND

Databases are widely used for data storage and access in computingapplications. Databases may include one or more tables that include orreference data that can be read, modified, or deleted using queries.Databases may be used for storing and/or accessing personal informationor other sensitive information. Secure storage and access of databasedata may be provided by encrypting and/or storing data in an encryptedform to prevent unauthorized access. In some cases, data sharing may bedesirable to let other parties perform queries against a set of data.

BRIEF DESCRIPTION OF THE DRAWINGS

The described embodiments and the advantages thereof may best beunderstood by reference to the following description taken inconjunction with the accompanying drawings. These drawings in no waylimit any changes in form and detail that may be made to the describedembodiments by one skilled in the art without departing from the spiritand scope of the described embodiments.

FIG. 1A is a block diagram depicting an example computing environment inwhich the methods disclosed herein may be implemented.

FIG. 1B is a block diagram illustrating an example virtual warehouse.

FIG. 2 is a schematic block diagram of data that may be used toimplement a public or private data exchange in accordance with anembodiment of the present invention.

FIG. 3 is a schematic block diagram of components for implementing adata exchange in accordance with an embodiment of the present invention.

FIG. 4A is a process flow diagram of a method for controlled sharing ofdata among entities in a data exchange in accordance with an embodimentof the present invention.

FIG. 4B is a diagram illustrating data used for implementing privatesharing of data in accordance with an embodiment of the presentinvention.

FIG. 4C is a diagram illustrating a secure view for implementing privatesharing of data in accordance with an embodiment of the presentinvention.

FIG. 5 is a process flow diagram of a method for public sharing of dataamong entities in a data exchange in accordance with an embodiment ofthe present invention.

FIG. 6 is a process flow diagram of a method for performingbi-directional shares in a data exchange in accordance with anembodiment of the present invention.

FIG. 7 is a process flow diagram of a method for providing enriched datain a data exchange in accordance with an embodiment of the presentinvention.

FIG. 8A is a block diagram illustrating a network environment in which adata provider may share data via a cloud computing service.

FIG. 8B is a block diagram illustrating a network environment in whichan exchange administrator may manage membership of a data exchangeimplemented via a cloud computing service.

FIG. 9 is an example private data exchange in accordance with anembodiment of the present invention.

FIG. 10 is a diagram illustrating an example secure view of shared datafrom a private data exchange.

FIG. 11 is a diagram illustrating an example tunneling of a data listingbetween two private data exchanges.

FIG. 12 is a diagram illustrating an example data query and deliveryservice according to some embodiments of the invention.

FIGS. 13A and 13B are block diagrams illustrating example methods forproviding a private data exchange.

FIG. 14 is a block diagram of an example computing device that mayperform one or more of the operations described herein, in accordancewith some embodiments.

DETAILED DESCRIPTION

Data providers often have data assets that are cumbersome to share. Adata asset may be data that is of interest to another entity. Forexample, a large online retail company may have a data set that includesthe purchasing habits of millions of customers over the last ten years.This data set may be large. If the online retailer wishes to share allor a portion of this data with another entity, the online retailer mayneed to use old and slow methods to transfer the data, such as afile-transfer-protocol (FTP), or even copying the data onto physicalmedia and mailing the physical media to the other entity. This hasseveral disadvantages. First, it is slow. Copying terabytes or petabytesof data can take days. Second, once the data is delivered, the sharercannot control what happens to the data. The recipient can alter thedata, make copies, or share it with other parties. Third, the onlyentities that would be interested in accessing such a large data set insuch a manner are large corporations that can afford the complexlogistics of transferring and processing the data as well as the highprice of such a cumbersome data transfer. Thus, smaller entities (e.g.,“mom and pop” shops) or even smaller, more nimble cloud-focused startupsare often priced out of accessing this data, even though the data may bevaluable to their businesses. This may be because raw data assets aregenerally too unpolished and full of potentially sensitive data to justoutright sell to other companies. Data cleaning, de-identification,aggregation, joining, and other forms of data enrichment need to beperformed by the owner of data before it is shareable with anotherparty. This is time-consuming and expensive. Finally, it is difficult toshare data assets with many entities because traditional data sharingmethods do not allow scalable sharing for the reasons mentioned above.Traditional sharing methods also introduce latency and delays in termsof all parties having access to the most recently-updated data.

A private data exchange may allow data providers to more easily andsecurely share their data assets with other entities. A private dataexchange can be under the data provider's brand, and the data providermay control who can gain access to it. The private data exchange may befor internal use only, or may also be opened to customers, partners,suppliers, or others. The data provider may control what data assets arelisted as well as control who has access to which sets of data. Thisallows for a seamless way to discover and share data both within a dataprovider's organization and with its business partners.

The private data exchange may be facilitated by a cloud computingservice such as SNOWFLAKE, and allows data providers to offer dataassets directly from their own online domain (e.g., website) in aprivate online marketplace with their own branding. The private dataexchange may provide a centralized, managed hub for an entity to listinternally or externally-shared data assets, inspire data collaboration,and also to maintain data governance and to audit access. With theprivate data exchange, data providers may be able to share data withoutcopying it between companies. Data providers may invite other entitiesto view their data listings, control which data listings appear in theirprivate online marketplace, control who can access data listings and howothers can interact with the data assets connected to the listings. Thismay be thought of as a “walled garden” marketplace, in which visitors tothe garden must be approved and access to certain listings may belimited.

As an example, Company A may be a consumer data company that hascollected and analyzed the consumption habits of millions of individualsin several different categories. Their data sets may include data in thefollowing categories: online shopping, video streaming, electricityconsumption, automobile usage, internet usage, clothing purchases,mobile application purchases, club memberships, and online subscriptionservices. Company A may desire to offer these data sets (or subsets orderived products of these data sets) to other entities. For example, anew clothing brand may wish to access data sets related to consumerclothing purchases and online shopping habits. Company A may support apage on its website that is or functions substantially similar to aprivate data exchange, where a data consumer (e.g., the new clothingbrand) may browse, explore, discover, access and potentially purchasedata sets directly from Company A. Further, Company A may control: whocan enter the private data exchange, the entities that may view aparticular listing, the actions that an entity may take with respect toa listing (e.g., view only), and any other suitable action. In addition,a data provider may combine its own data with other data sets from,e.g., a public data exchange, and create new listings using the combineddata.

A private data exchange may be an appropriate place to discover,assemble, clean, and enrich data to make it more monetizable. A largecompany on a private data exchange may assemble data from across itsdivisions and departments, which could become valuable to anothercompany. In addition, participants in a private ecosystem data exchangemay work together to join their datasets together to jointly create auseful data product that any one of them alone would not be able toproduce. Once these joined datasets are created, they may be listed on apublic or private data exchange.

The systems and methods described herein provide a flexible and scalabledata warehouse using a new data processing platform. In someembodiments, the described systems and methods leverage a cloudinfrastructure that supports cloud-based storage resources, computingresources, and the like. Example cloud-based storage resources offersignificant storage capacity available on-demand at a low cost. Further,these cloud-based storage resources may be fault-tolerant and highlyscalable, which can be costly to achieve in private data storagesystems. Example cloud-based computing resources are available on-demandand may be priced based on actual usage levels of the resources.Typically, the cloud infrastructure is dynamically deployed,reconfigured, and decommissioned in a rapid manner.

In the described systems and methods, a data storage system utilizes anSQL (Structured Query Language)-based relational database. However,these systems and methods are applicable to any type of database, andany type of data storage and retrieval platform, using any data storagearchitecture and using any language to store and retrieve data withinthe data storage and retrieval platform. The systems and methodsdescribed herein further provide a multi-tenant system that supportsisolation of computing resources and data between differentcustomers/clients and between different users within the samecustomer/client.

The systems and methods described herein further provide a method formanaging membership in a private data exchange. The private dataexchange may be facilitated by a cloud computing service such asSNOWFLAKE, and allows data providers to offer a set of listings directlyfrom their own online domain (e.g., website) in a private onlinemarketplace with their own branding. Each listing may include data fromone or more data sets stored on the cloud computing service. Membershipmay be managed by an exchange administrator of the data exchange. Insome embodiments, the exchange administrator may add a new member to thedata exchange by sending an invite to an email address or cloudcomputing service account of the new member. The exchange administratormay assign an account type to the new member, the account typecomprising at least one of a consumer type, provider type, or exchangeadministrator type. Each of the consumer type, the provider type, andthe exchange administrator type may be associated with one or morerights regarding the set of listings, such as viewing listings, viewingand accessing data within listings, and creating listings. Thus, the newmember may have a set of rights based on the account type. The exchangeadministrator may modify the set of rights of the new member withrespect to one or more listings from the set of listings based on a setof visibility and access rules for each of the set of listings.

FIG. 1A is a block diagram of an example computing environment 100 inwhich the systems and methods disclosed herein may be implemented. Inparticular, a cloud computing platform 110 may be implemented, such asAMAZON WEB SERVICES™ (AWS), MICROSOFT AZURE™, GOOGLE CLOUD™, or thelike. As known in the art, a cloud computing platform 110 providescomputing resources and storage resources that may be acquired(purchased) or leased and configured to execute applications and storedata.

The cloud computing platform 110 may host a cloud computing service 112that facilitates storage of data on the cloud computing platform 110(e.g. data management and access) and analysis functions (e.g. SQLqueries, analysis), as well as other computation capabilities (e.g.,secure data sharing between users of the cloud computing platform 110).The cloud computing platform 110 may include a three-tier architecture:data storage 140, query processing 130, and cloud services 120.

Data storage 140 may facilitate the storing of data on the cloudcomputing platform 110 in one or more cloud databases 141. Data storage140 may use a storage service such as AMAZON S3 to store data and queryresults on the cloud computing platform 110. In particular embodiments,to load data into the cloud computing platform 110, data tables may behorizontally partitioned into large, immutable files which may beanalogous to blocks or pages in a traditional database system. Withineach file, the values of each attribute or column are grouped togetherand compressed using a scheme sometimes referred to as hybrid columnar.Each table has a header which, among other metadata, contains theoffsets of each column within the file.

In addition to storing table data, data storage 140 facilitates thestorage of temp data generated by query operations (e.g., joins), aswell as the data contained in large query results. This may allow thesystem to compute large queries without out-of-memory or out-of-diskerrors. Storing query results this way may simplify query processing asit removes the need for server-side cursors found in traditionaldatabase systems.

Query processing 130 may handle query execution within elastic clustersof virtual machines, referred to herein as virtual warehouses or datawarehouses. Thus, query processing 130 may include one or more virtualwarehouses 131, which may also be referred to herein as data warehouses.The virtual warehouses 131 may be one or more virtual machines operatingon the cloud computing platform 110. The virtual warehouses 131 may becompute resources that may be created, destroyed, or resized at anypoint, on demand. This functionality may create an “elastic” virtualwarehouse that expands, contracts, or shuts down according to the user'sneeds. Expanding a virtual warehouse involves generating one or morecompute nodes 132 to a virtual warehouse 131. Contracting a virtualwarehouse involves removing one or more compute nodes 132 from a virtualwarehouse 131. More compute nodes 132 may lead to faster compute times.For example, a data load which takes fifteen hours on a system with fournodes might take only two hours with thirty-two nodes.

Cloud services 120 may be a collection of services that coordinateactivities across the cloud computing service 110. These services tietogether all of the different components of the cloud computing service110 in order to process user requests, from login to query dispatch.Cloud services 120 may operate on compute instances provisioned by thecloud computing service 110 from the cloud computing platform 110. Cloudservices 120 may include a collection of services that manage virtualwarehouses, queries, transactions, data exchanges, and the metadataassociated with such services, such as database schemas, access controlinformation, encryption keys, and usage statistics. Cloud services 120may include, but not be limited to, authentication engine 121,infrastructure manager 122, optimizer 123, exchange manager 124,security 125 engine, and metadata storage 126.

FIG. 1B is a block diagram illustrating an example virtual warehouse131. The exchange manager 124 may facilitate the sharing of data betweendata providers and data consumers, using, for example, a private dataexchange. For example, cloud computing service 112 may manage thestorage and access of a database 108. The database 108 may includevarious instances of user data 150 for different users, e.g. differententerprises or individuals. The user data may include a user database152 of data stored and accessed by that user. The user database 152 maybe subject to access controls such that only the owner of the data isallowed to change and access the database 112 upon authenticating withthe cloud computing service 112. For example, data may be encrypted suchthat it can only be decrypted using decryption information possessed bythe owner of the data. Using the exchange manager 124, specific datafrom a user database 152 that is subject to these access controls may beshared with other users in a controlled manner according to the methodsdisclosed herein. In particular, a user may specify shares 154 that maybe shared in a public or private data exchange in an uncontrolled manneror shared with specific other users in a controlled manner as describedabove. A “share” encapsulates all of the information required to sharedata in a database. A share may include at least three pieces ofinformation: (1) privileges that grant access to the database(s) and theschema containing the objects to share, (2) the privileges that grantaccess to the specific objects (e.g., tables, secure views, and secureUDFs), and (3) the consumer accounts with which the database and itsobjects are shared. When data is shared, no data is copied ortransferred between users. Sharing is accomplished through the cloudservices 120 of cloud computing service 110.

Sharing data may be performed when a data provider creates a share of adatabase in the data provider's account and grants access to particularobjects (e.g., tables, secure views, and secure user-defined functions(UDFs)). Then a read-only database may be created using informationprovided in the share. Access to this database may be controlled by thedata provider.

Shared data may then be used to process SQL queries, possibly includingjoins, aggregations, or other analysis. In some instances, a dataprovider may define a share such that “secure joins” are permitted to beperformed with respect to the shared data. A secure join may beperformed such that analysis may be performed with respect to shareddata but the actual shared data is not accessible by the data consumer(e.g., recipient of the share). A secure join may be performed asdescribed in U.S. application Ser. No. 16/368,339, filed Mar. 18, 2019.

User devices 101-104, such as laptop computers, desktop computers,mobile phones, tablet computers, cloud-hosted computers, cloud-hostedserverless processes, or other computing processes or devices may beused to access the virtual warehouse 131 or cloud service 120 by way ofa network 105, such as the Internet or a private network.

In the description below, actions are ascribed to users, particularlyconsumers and providers. Such actions shall be understood to beperformed with respect to devices 101-104 operated by such users. Forexample, notification to a user may be understood to be a notificationtransmitted to devices 101-104, an input or instruction from a user maybe understood to be received by way of the user's devices 101-104, andinteraction with an interface by a user shall be understood to beinteraction with the interface on the user's devices 101-104. Inaddition, database operations (joining, aggregating, analysis, etc.)ascribed to a user (consumer or provider) shall be understood to includeperforming of such actions by the cloud computing service 110 inresponse to an instruction from that user.

FIG. 2 is a schematic block diagram of data that may be used toimplement a public or private data exchange in accordance with anembodiment of the present invention. The exchange manager 124 mayoperate with respect to some or all of the illustrated exchange data200, which may be stored on the platform executing the exchange manager124 (e.g., the cloud computing platform 110) or at some other location.The exchange data 200 may include a plurality of listings 202 describingdata that is shared by a first user (“the provider”). The listings 202may be listings in a private data exchange or in a public data exchange.The access controls, management, and governance of the listings may besimilar for both a public data exchange and a private data exchange.

A listing 202 may include metadata 204 describing the shared data. Themetadata 204 may include some or all of the following information: anidentifier of the sharer of the shared data, a URL associated with thesharer, a name of the share, a name of tables, a category to which theshared data belongs, an update frequency of the shared data, a catalogof the tables, a number of columns and a number of rows in each table,as well as name for the columns. The metadata 204 may also includeexamples to aid a user in using the data. Such examples may includesample tables that include a sample of rows and columns of an exampletable, example queries that may be run against the tables, example viewsof an example table, example visualizations (e.g., graphs, dashboards)based on a table's data. Other information included in the metadata 204may be metadata for use by business intelligence tools, text descriptionof data contained in the table, keywords associated with the table tofacilitate searching, a link (e.g., URL) to documentation related to theshared data, and a refresh interval indicating how frequently the shareddata is updated along with the date the data was last updated.

The listing 202 may include access controls 206, which may beconfigurable to any suitable access configuration. For example, accesscontrols 206 may indicate that the shared data is available to anymember of the private exchange without restriction (an “any share” asused elsewhere herein). The access controls 206 may specify a class ofusers (members of a particular group or organization) that are allowedto access the data and/or see the listing. The access controls 206 mayspecify that a “point-to-point” share (see discussion of FIG. 4) inwhich users may request access but are only allowed access upon approvalof the provider. The access controls 206 may specify a set of useridentifiers of users that are excluded from being able to access thedata referenced by the listing 202.

Note that some listings 202 may be discoverable by users without furtherauthentication or access permissions whereas actual accesses are onlypermitted after a subsequent authentication step (see discussion ofFIGS. 4 and 6). The access controls 206 may specify that a listing 202is only discoverable by specific users or classes of users.

Note also that a default function for listings 202 is that the datareferenced by the share is not exportable by the consumer.Alternatively, the access controls 206 may specify that this notpermitted. For example, access controls 206 may specify that secureoperations (secure joins and secure functions as discussed below) may beperformed with respect to the shared data such that viewing andexporting of the shared data is not permitted.

In some embodiments, once a user is authenticated with respect to alisting 202, a reference to that user (e.g., user identifier of theuser's account with the virtual warehouse 131) is added to the accesscontrols 206 such that the user will subsequently be able to access thedata referenced by the listing 202 without further authentication.

The listing 202 may define one or more filters 208. For example, thefilters 208 may define specific user identifiers 214 of users that mayview references to the listing 202 when browsing the catalog 220. Thefilters 208 may define a class of users (users of a certain profession,users associated with a particular company or organization, users withina particular geographical area or country) that may view references tothe listing 202 when browsing the catalog 220. In this manner, a privateexchange may be implemented by the exchange manager 124 using the samecomponents. In some embodiments, an excluded user that is excluded fromaccessing a listing 202, i.e. adding the listing 202 to the consumedshares 156 of the excluded user, may still be permitted to view arepresentation of the listing when browsing the catalog 220 and mayfurther be permitted to request access to the listing 202 as discussedbelow. Requests to access a listing by such excluded users and otherusers may be listed in an interface presented to the provider of thelisting 202. The provider of the listing 202 may then view demand foraccess to the listing and choose to expand the filters 208 to permitaccess to excluded users or classes of excluded users (e.g., users inexcluded geographic regions or countries).

Filters 208 may further define what data may be viewed by a user. Inparticular, filters 208 may indicate that a user that selects a listing202 to add to the consumed shares 156 of the user is permitted to accessthe data referenced by the listing but only a filtered version that onlyincludes data associated with the identifier 214 of that user,associated with that user's organization, or specific to some otherclassification of the user. In some embodiments, a private exchange isby invitation: users invited by a provider to view listings 202 of aprivate exchange are enabled to do by the exchange manager 124 uponcommunicating acceptance of an invitation received from the provider.

In some embodiments, a listing 202 may be addressed to a single user.Accordingly, a reference to the listing 202 may be added to a set of“pending shares” that is viewable by the user. The listing 202 may thenbe added to a group of shares of the user upon the user communicatingapproval to the exchange manager 124.

The listing 202 may further include usage data 210. For example, thecloud computing service 112 may implement a credit system in whichcredits are purchased by a user and are consumed each time a user runs aquery, stores data, or uses other services implemented by the cloudcomputing service 112. Accordingly, usage data 210 may record an amountof credits consumed by accessing the shared data. Usage data 210 mayinclude other data such as a number of queries, a number of aggregationsof each type of a plurality of types performed against the shared data,or other usage statistics. In some embodiments, usage data for a listing202 or multiple listings 202 of a user is provided to the user in theform of a shared database, i.e. a reference to a database including theusage data is added by the exchange manager 124 to the consumed sharesof the user.

The listing 202 may also include a heat map 211, which may represent thegeographical locations in which users have clicked on that particularlisting. The cloud computing service 110 may use the heat map to makereplication decisions or other decisions with the listing. For example,a private data exchange may display a listing that contains weather datafor Georgia, USA. The heat map 211 may indicate that many users inCalifornia are selecting the listing to learn more about the weather inGeorgia. In view of this information, the cloud computing service 110may replicate the listing and make it available in a database whoseservers are physically located in the western United States, so thatconsumers in California may have access to the data. In someembodiments, an entity may store its data on servers located in thewestern United States. A particular listing may be very popular toconsumers. The cloud computing service 110 may replicate that data andstore it in servers located in the eastern United States, so thatconsumers in the Midwest and on the East Coast may also have access tothat data.

The listing 202 may also include one or more tags 213. The tags 213 mayfacilitate simpler sharing of data contained in one or more listings. Asan example, a large company may have a human resources (HR) listingcontaining HR data for its internal employees on a private dataexchange. The HR data may contain ten types of HR data (e.g., employeenumber, selected health insurance, current retirement plan, job title,etc.). The HR listing may be accessible to 100 people in the company(e.g., everyone in the HR department). Management of the HR departmentmay wish to add an eleventh type of HR data (e.g., an employee stockoption plan). Instead of manually adding this to the HR listing andgranting each of the 100 people access to this new data, management maysimply apply an HR tag to the new data set and that can be used tocategorize the data as HR data, list it along with the HR listing, andgrant access to the 100 people to view the new data set.

The listing 202 may also include version metadata 215. Version metadata215 may provide a way to track how the datasets are changed. This mayassist in ensuring that the data that is being viewed by one entity isnot changed prematurely. For example, if a company has an original dataset and then releases an updated version of that data set, the updatescould interfere with another user's processing of that data set, becausethe update could have different formatting, new columns, and otherchanges that may be incompatible with the current processing mechanismof the recipient user. To remedy this, the cloud computing service 112may track version updates using version metadata 215. The cloudcomputing service 112 may ensure that each data consumer accesses thesame version of the data until they accept an updated version that willnot interfere with current processing of the data set.

The exchange data 200 may further include user records 212. The userrecord 212 may include data identifying the user associated with theuser record 212, e.g. an identifier (e.g., warehouse identifier) of auser having user data 150 in service database 128 and managed by thevirtual warehouse 131.

The user record 212 may list shares associated with the user, e.g.,reference listings 202 created by the user. The user record 212 may listshares consumed by the user, e.g. reference listings 202 created byanother user and that have been associated to the account of the useraccording to the methods described herein. For example, a listing 202may have an identifier that will be used to reference it in the sharesor consumed shares of a user record 212.

The exchange data 200 may further include a catalog 220. The catalog 220may include a listing of all available listings 202 and may include anindex of data from the metadata 204 to facilitate browsing and searchingaccording to the methods described herein. In some embodiments, listings202 are stored in the catalog in the form of JavaScript Object Notation(JSON) objects.

Note that where there a multiple instances of the virtual warehouse 131on different cloud computing platforms, the catalog 220 of one instanceof the virtual warehouse 131 may store listings or references tolistings from other instances on one or more other cloud computingplatforms 110. Accordingly, each listing 202 may be globally unique(e.g., be assigned a globally unique identifier across all of theinstances of the virtual warehouse 131). For example, the instances ofthe virtual warehouses 131 may synchronize their copies of the catalog220 such that each copy indicates the listings 202 available from allinstances of the virtual warehouse 131. In some instances, a provider ofa listing 202 may specify that it is to be available on only onspecified on or more computing platforms 110.

In some embodiments, the catalog 220 is made available on the Internetsuch that it is searchable by a search engine such as BING or GOOGLE.The catalog may be subject to a search engine optimization (SEO)algorithm to promote its visibility. Potential consumers may thereforebrowse the catalog 220 from any web browser. The exchange manager 124may expose uniform resource locators (URLs) linked to each listing 202.This URL may be searchable can be shared outside of any interfaceimplemented by the exchange manager 124. For example, the provider of alisting 202 may publish the URLs for its listings 202 in order topromote usage of its listing 202 and its brand.

FIG. 3 illustrates various components 300-310 that may be included inthe exchange manager 124. A creation module 300 may provide an interfacefor creating listings 202. For example, a webpage interface to thevirtual warehouse 131 that enables a user on a devices 101-104 to selectdata, e.g. a specific table in user data 150 of the user, for sharingand enter values defining some or all of the metadata 204, accesscontrols 206, and filters 208. In some embodiments, creation may beperformed by a user by way of SQL commands in an SQL interpreterexecuting on the cloud computing platform 110 and accessed by way of awebpage interface on a user device 101-104.

A validation module 302 may validate information provided by a providerwhen attempting to create a listing 202. Note that in some embodimentsthe actions ascribed to the validation module 302 may be performed by ahuman reviewing the information provided by the provider. In otherembodiments, these actions are performed automatically. The validationmodule 302 may perform, or facilitate performing by a human operator ofvarious functions. These functions may include verifying that themetadata 204 is consistent with the shared data to which it references,verifying that the shared data referenced by metadata 204 is not pirateddata, personal identification information (PII), personal healthinformation (PHI) or other data fro which sharing is undesirable orillegal. The validation module 302 may also facilitate the verificationthat the data has been updated within a threshold period of time (e.g.,within the last twenty-four hours). The validation module 302 may alsofacilitate verifying that the data is not static or not available fromother static public sources. The validation module 302 may alsofacilitate verifying that the data is more than merely a sample (e.g.,that the data is sufficiently complete to be useful). For example,geographically limited data may be undesirable whereas an aggregation ofdata that is not otherwise limited may still be of use.

The exchange manager 124 may include a search module 304. The searchmodule 304 may implement a webpage interface that is accessible by auser on a user devices 101-104 in order to invoke searches for searchstrings with respect to the metadata in the catalog 220, receiveresponses to searches, and select references to listings 202 in searchresults for adding to the consumed shares 156 of the user record 212 ofthe user performing the search. In some embodiments, searches may beperformed by a user by way of SQL commands in an SQL interpreterexecuting on the cloud computing platform 102 and accessed by way of awebpage interface on user devices 101-104. For example, searching forshares may be performed by way of SQL queries against the catalog 220within the SQL engine 310 discussed below.

The search module 304 may further implement a recommendation algorithm.For example, the recommendation algorithm could recommend other listing202 for a user based on other listings in the user's consumed shares 156or formerly in the user's consumed shares. Recommendations could bebased on logical similarity: one source of weather data leads to arecommendation for a second source of weather data. Recommendationscould be based on dissimilarity: one listing is for data in one domain(geographic area, technical field, etc.) results in a listing for adifferent domain to facilitate complete coverage by the user's analysis(different geographic area, related technical field, etc.).

The exchange manager 124 may include an access management module 306. Asdescribed above, a user may add a listing 202. This may requireauthentication with respect to the provider of the listing 202. Once alisting 202 is added to the consumed shares 156 of the user record 212of a user, the user may be either (a) required to authenticate each timethe data referenced by the listing 202 is accessed or (b) beautomatically authenticated and allowed to access the data once thelisting 202 is added. The access management module 306 may manageautomatic authentication for subsequent access of data in the consumedshares 156 of a user in order to provide seamless access of the shareddata as if it was part of the user data 150 of that user. To that end,the access management module 306 may access access controls 206 of thelisting 202, certificates, tokens, or other authentication material inorder to authenticate the user when performing accesses to shared data.

The exchange manager 124 may include a joining module 308. The joiningmodule 308 manages the integration of shared data referenced by consumedshares 156 of a user with one another, i.e. shared data from differentproviders, and with a user database 152 of data owned by the user. Inparticular, the joining module 308 may manage the execution of queriesand other computation functions with respect to these various sources ofdata such that their access is transparent to the user. The joiningmodule 308 may further manage the access of data to enforce restrictionson shared data, e.g. such that analysis may be performed and the resultsof the analysis displayed without exposing the underlying data to theconsumer of the data where this restriction is indicated by the accesscontrols 206 of a listing 202.

The exchange manager 124 may further include a standard query language(SQL) engine 310 that is programmed to receive queries from a user andexecute the query with respect to data referenced by the query, whichmay include consumed shares 156 of the user and the user data 112 ownedby the user. The SQL engine 310 may perform any query processingfunctionality known in the art. The SQL engine 310 may additionally oralternatively include any other database management tool or dataanalysis tool known in the art. The SQL engine 310 may define a webpageinterface executing on the cloud computing platform 102 through whichSQL queries are input and responses to SQL queries are presented

Referring to FIG. 4A, the illustrated method 400 may be executed by theexchange manager 124 in order to implement a point-to-point sharebetween a first user (“provider 402”) and a second user (“consumer404”).

The method 400 may include the provider entering 406 metadata. This mayinclude a user on devices 101-104 of the provider entering the metadatainto fields of a form in a webpage provided by the exchange manager 124.In some embodiments, entering 406 of metadata may be made using SQLcommands by way of the SQL engine 310. The items of metadata may includesome or all of those discussed above with respect to the metadata 204 ofa listing 202. Step 406 may include receiving other data for a listing202, such as access controls 206 and parameters defining a filter 208.

The provider 402 may then invoke, on the devices 101-104, submission ofthe form and the data entered. The exchange manager 124 may then verify408 the metadata and validate 410 the data referenced by the metadata.This may include performing some or all of the actions ascribed to thevalidation module 302. If the metadata and shared data are notsuccessfully verified 408 and validated 410, the exchange manager 124may notify the provider 402, such as by means of a notification throughthe web interface through which the metadata was submitted at step 406.

If the metadata and shared data are not successfully verified 408 andvalidated 410, the exchange manager 124 may notify the provider 402,such as by way of the web interface through which the metadata wassubmitted at step 406.

The exchange manager 124 may further create 412 a listing 202 includingthe data submitted at step 406 and may further create an entry in thecatalog 220. For example, keywords, descriptive text, and other items ofinformation in the metadata may be indexed to facilitate searching.

Note that steps 406-412 may be performed by means of an interfaceprovided to the provider 402. Such an interface may include any suitablefeatures including elements for inputting data (e.g., elements 204-210),and elements for generating a data listing. In addition, the interfacemay include elements to publish or unpublish a data listing to make thelisting un-viewable to at least some other users. The interface may alsoinclude an element to update versions of the data listing or to rollback to a prior version of the listing or of the metadata associatedwith the listing. The interface may also include a list of pendingrequests to add a data listing or to add members to the data exchange.The interface may also include an indication of the number and othernon-identifying information related to the data consumers who haveaccessed a given listing, as well as a representation of usage patternsof the data referenced by a listing by the data consumers of thatlisting.

Another user acting as a consumer 404 may then browse 414 the catalog.This may include accessing a publicly accessible webpage providing asearch interface to the catalog. This webpage may be external to thevirtual warehouse 131, i.e. accessible by users that are not logged intothe virtual warehouse 131. In other embodiments, only users that arelogged in to the virtual warehouse 131 are able to access the searchinterface. As noted above, browsing of the catalog 220 may be performedusing queries to the SQL engine 310 that reference the catalog 220. Forexample, user devices 101-104 may have a web-based interface to the SQLengine 310 through which queries against the catalog 220 are input bythe consumer 404 and transmitted to the SQL engine 310.

In response to the consumer's browsing activities, the exchange manager124 may display the catalog and perform 416 searches with respect to thecatalog to identify listings 202 having metadata corresponding toqueries or search strings submitted by the consumer 404. The manner inwhich this search is performed may be according to any search algorithmknown in the art. In the case of an SQL query, the query may beprocessed according to any approach for processing SQL queries known inthe art.

The exchange manager 124 may return results of a search string or SQLquery to the consumer's 404 devices 101-104, such as in the form of alisting of references to listings 202 identified according to the searchalgorithm or processing the SQL query. The listing may include items ofmetadata or links that the consumer 404 may select to invoke display ofmetadata. In particular, any of the items of metadata 204 of a listing202 may be displayed in the listing or linked to by an entry in thelisting corresponding to the search record 202.

Note that the exchange referenced in FIG. 4A may be a private exchangeor a public exchange. In particular, those listings 202 that aredisplayed and searched 416 and viewable by the consumer 404 duringbrowsing 414 may be limited to those having filters 208 that indicatethat the listing 202 is viewable by the consumer 404, an organization ofthe consumer, or some other classification to which the consumer 404belongs. Where the exchange is public, then the consumer 404 is notrequired to meet any filter criteria in some embodiments.

The method 400 may include the consumer 404 requesting 418 to accessdata corresponding to a listing 202. For example, by selecting an entryin the listing on the devices 101-104 of the consumer 404, which invokestransmission of a request to the exchange manager 124 to add the listing202 corresponding to the entry to the consumed shares 156 in the userrecord 212 of the consumer 404.

In the illustrated example, the listing 202 of the selected entry hasaccess controls 206. Accordingly, the exchange manager 124 may forward420 the request to the provider 402 along with an identifier of theconsumer 404. The consumer 404 and provider 402 may then interact to oneor both of (a) authenticate (login) 424 the consumer 404 with respect tothe provider 402 and (b) process 424 payment for access of the datareferenced by the listing 202. This interaction may be according to anyapproach to logging in or authenticating or known in the art. Likewise,any approach for processing payment between parties may be implemented.In some embodiments, the data warehouse module may provide a rebate tothe provider 402 due to credits consumed by the consumer 404 whenaccessing the shared data of the provider. Credits may be units of usagepurchased by a user that are then consumed in response to services ofthe virtual warehouse 131 used by the consumer 404, e.g. queries andother analytics performed on data hosted by the virtual warehouse 131.The interaction may be directly between devices 126 of the consumer 404and provider 402 or may be performed by way of the exchange manager 124.In some embodiments, the exchange manager 124 authenticates the consumer404 using the access control information 206 such that interaction withthe provider 402 is not needed. Likewise, the listing 202 may definepayment terms such that the exchange manager 124 processes paymentwithout requiring interaction with the provider 402. Once the provider402 determines that the consumer 404 is authenticated and authorized toaccess the data referenced by the listing 202, the provider 402 maynotify 426 the exchange manager 124 that the consumer 404 may access thedata referenced by the listing 202. In response, the exchange manager124 adds 428 a reference to the listing 202 to the consumed shares 156in the user record 212 of the consumer 404.

Note that in some instances a listing 202 does not list specific data,but rather references a particular cloud service 120, e.g. the brandname or company name of a service. Accordingly, the request to accessthe listing 202 is a request to access user data 150 of the consumermaking the request. Accordingly, steps 422, 424, 426 includingauthenticating the consumer 404 with respect to the authenticationengine 121 such that the cloud service 120 can verify the identity ofthe consumer 404 and inform the exchange manager 124 of which data toshare with the consumer 404 and to indicate that the consumer 404 isauthorized to access that data.

In some embodiments, this may be implemented using a “single sign on”approach in which the consumer 404 authenticates (logs in) once withrespect to the cloud service 120 and thereafter is enabled to access theconsumers 404 data in the service database 158. For example, theexchange manager 124 may present an interface to the cloud service 120on the devices 101-104 of the consumer 404. The consumer 404 inputsauthentication information (username and password, certificate, token,etc.) into the interface and this information is forwarded to theauthentication engine 121 of the cloud service 120. The authenticationinformation processes the authentication information and, if theinformation corresponds to a user account, notifies the exchange manager124 that the consumer 404 is authenticated with respect to that useraccount. The exchange manager 124 may then identify the user data 150for that user account and create a database referencing it. A referenceto that database is then added to the consumed shares 156 of theconsumer 404.

In some embodiments, the user's authentication with respect to thevirtual warehouse 131 is sufficient to authenticate the user withrespect to the cloud service 120 such that steps 422, 424 are omitted inview of the prior authentication of the consumer 404. For example, thevirtual warehouse 131 may be indicated by the consumer 404 to the cloudservice 120 to be authorized to verify the identity of the consumer 404.

In some embodiments, the exchange manager 124 authenticates the consumer404 using the access control information 206 such that interaction withthe provider 402 is not needed. Likewise, the listing 202 may definepayment terms such that the exchange manager 124 processes paymentwithout requiring interaction with the provider 402. Accordingly, insuch embodiments, step 422 is performed by the exchange manager 124 andstep 426 is omitted. The exchange manager 124 then performs step 428once the consumer 404 is authenticated and/or provided required payment.

In some embodiments, adding a listing 202 to the consumed shares of aconsumer 404 may further include receiving, from the consumer 404,consent to terms presented to the consumer 404. In some embodiments,where the terms of the agreement are changed by a provider 402 after aconsumer 404 has added the listing 202 according to the method 400 orother method described herein, the exchange manager 124 may require theconsumer 404 to agree to the changed terms before being allowed tocontinue to access the data referenced by the listing 202.

Adding 428 the data reference by the listing 202 may include creating adatabase referencing the data. A reference to this database may then beadded to the consumed shares 156 and this database may then be used toprocess queries referencing the data referenced by the share record.Adding 428 the data may include adding data filtered according tofilters 208. For example, data referenced by the listing 202 (e.g., afiltered view of the data) and that is associated with the consumer 404,organization of the consumer 404, or some other classification of theconsumer 404.

In some embodiments, adding the listing 202 to the user record 212 mayinclude changing the access controls 206 of the listing 202 to referencethe identity data 214 of the consumer 404 such that attempts to accessthe data referenced by the listing 202 will be permitted and executed bythe exchange manager 124.

The consumer 404 may then input 432 queries to the SQL engine 310 by wayof the consumer's devices 101-104. The queries may reference the datareferenced in the listing 202 added at step 428 as well as other datareferenced in the user database 152 and consumed shares 156. The SQLengine 310 then processes 430 the queries using the database created atstep 428 and returns the result to the consumer 404 or creates views,materialized views, or other data that may be accessed or analyzed bythe user. As noted above, the data of consumed shares operated upon bythe queries may have been previously filtered to include only datarelating to the consumer 404. Accordingly, different consumers 404adding the same listing 202 to their consumed shares 156 will seedifferent versions of the database referenced by the listing 202.

Referring to FIG. 4B, in some embodiments, the private sharing of dataand filtering of data according to identify of the consumer 404 may beimplemented using the illustrated data structures. For example, theservice database 158 of the provider 402 may include a customer map 434that includes entries for customer identifiers 436 of users of theservice provided by the provider 402, e.g. a service implemented by thecloud service 120 of the server and the customer identifier 436 being anidentifier for authenticating with the authentication interface 120. Thecustomer map 434 may map each customer identifier 436 to a warehouseidentifier 438, i.e. a user identifier used by a user to authenticatewith the virtual warehouse 131 such that the same user corresponds toboth identifiers 436, 438. The mapping between the identifiers 436 and438 may be performed by authenticating as described above (e.g., thesingle sign on approach described above).

The customer map 434 may further include a reference 440 to anentitlement table 442, which may be one of a plurality of entitlementtables 442. Each entitlement table 442 defines which of one or moretables 444 of the provider 402 may be accessed with the customer ID 436to which it is mapped. The entitlement table 442 may further definecolumns of a table 444 that can be accessed with the customer ID 436.The entitlement table 442 may further define rows or types of rows basedon one or more filtration criteria of a table 444 that can be accessedwith the customer ID 436. The entitlement table 442 may further define aschema for a table 444 that can be accessed with the customer ID 436.

A listing 202 for a table 444 may therefore specify that access to adata table 444 is to be performed as defined by the customer map 434.For example, referring to FIG. 4C, when a consumer 404 requests to add alisting 202 for a database for which access is defined according to thecustomer map, the exchange manager 124 may create a secure view 446according to the customer identifier 436 and entitlement table 442mapped to the warehouse identifier 438 of the consumer 404. The secureview may be generated by performing an inner join of the data tables 444of the database specified in the entitlement table 442 (or portionsthereof as specified in the entitlement table 442) that is filteredaccording to the customer identifier 436 such that a result of the joinincludes only data for the specific customer identifier 436 and includesonly those portions of the database (tables 444 and/or portions oftables 444) specified in the entitlement table 442. The manner in whichthe secure view is generated may be as described in U.S. applicationSer. No. 16/055,824 filed Aug. 6, 2018, and entitled SECURE DATA SHARINGIN A MULTI-TENANT DATABASE and U.S. application Ser. No. 16/241,463filed Jan. 7, 2019 and entitled SECURE DATA SHARING IN A MULTI-TENANTDATABASE.

FIG. 5 illustrates an alternative method 500 for sharing data that maybe performed when the consumer requests 418 to add a listing 202 that isavailable to the public or to all users of a private exchange. In thatcase, the exchange manager 124 adds 428 the reference to the listing 202to the consumed shares 156 of the consumer 404 and authentication orpayment steps are omitted. Step 428 may be performed as described aboveexcept that no change to access controls 206 is performed. Likewise,steps 430 and 432 may be performed with respect to the shared data asdescribed above. The exchange of FIG. 5 could be a public exchange or aprivate exchange as described above with respect to FIG. 4. FIG. 5illustrates the case where if a listing 202 is viewable (i.e. filtercriteria permit viewing by the consumer 404 as described above), theconsumer 404 is able to add the listing 202 to the consumed shares 156of the consumer 404 without further authentication or payment.

Note that when a listing 202 is added to the consumed shares 156 of auser according to any of the methods disclosed herein, the exchangemanager 124 may notify consumers of the listing 202 when the datareferenced by the listing 202 is updated.

Referring to FIG. 6, in some embodiments, a method 600 may include aconsumer 404 browsing a catalog and selecting a listing 202 as describedfor the other methods described herein (see, e.g., FIGS. 4A and 5), fromthe exchange manager 124, a bidirectional share with respect to the datareferenced by the listing (“the shared data”) and additional data in theuser's database 112 (“the user's data”). Note that in some embodimentsthe listing 202 of the provider 402 does not reference any specific data(e.g., a specific table or database) and instead offers to perform aservice with respect to data provided by the consumer 404. Accordingly,in such instances “the shared data” as discussed below may be understoodto be replaced with “the offered service.”

In response to this request, the exchange manager 124 implements 604 apoint-to-point share of the shared data with respect to the consumer 404and the provider 402. This may be performed as described above withrespect to FIG. 4A, e.g. include authentication of the consumer 404 andpossibly filtering of the shared data to only include data associatedwith the consumer 404 as described above. The exchange manager 124 mayfurther implement a point-to-point share of the user's data with respectto the provider 402 as described with respect to FIG. 4A except: (a) theconsumer 404 acts as the provider and the provider 402 acts as theconsumer for the user's data and the user's data is added to theconsumed shares 156 of the provider 402 and (b) the consumer 404 neednot create a listing 202 for the user's data and the user's data neednot be listed in the catalog 220.

Following step 606, both the consumer 404 or the provider 402 haveaccess to the shared data and the user's data. Either may then runqueries against both of these, join them, perform aggregations on thejoined data, or perform any other actions known in the art with respectto multiple databases.

In some embodiments, a bi-directional share may include, or be requestedby the consumer 404 to include, the provider 402 also joining 608 theshared data and the user data to obtain joined data and returning 610 areference to the joined data to the exchange manager 124 with a requestto add 612 a reference to the joined data to the consumed shares 156 ofthe consumer 404, which the exchange manager 124 does.

Accordingly, the consumer 404 will now have access to the joined data.Step 608 may further include performing other actions (aggregations,analysis) on the user data and shared data either before or afterjoining. Step 608 may be performed by the virtual warehouse 131 inresponse to the request form the consumer 404 to do so.

The result of the join may be either (a) a new database that is a resultof the join or (b) a joined database view that defines a join of theshared data and the user data. The result from step 608 (joining,aggregating, analyzing, etc.) may alternatively be added to the originalshare performed at step 606, 608, e.g. a view (materialized ornon-materialized) defining the operations performed at step 608. Steps608-612 may also be performed by the virtual warehouse 131 in responseto a request from the consumer 404 or provider 402 to do soindependently from the request made at step 602.

In many instances there are many consumers 404 that attempt to performbi-directional shares with respect to the provider 402 and theseconsumers 404 may seek bi-directional shares with respect to their userdata that may be in many different formats (schemas) that may bedifferent from a schema used by the shared data of the provider 402.Accordingly, step 608 may include a transformation step. Thetransformation step maps a source schema of the user's data to a targetschema of the shared data. The transformation may be a statictransformation provided by a human operator. The transformation may beaccording to an algorithm that maps column labels of the source schemato corresponding column labels of the target schema. The algorithm mayinclude a machine learning or artificial intelligence model that istrained to perform the transformation. For example, a plurality oftraining data entries may be specified by human annotators that eachinclude as an input a source schema and as an output include a mappingbetween the source schema and the target schema. These entries may thenbe used to train a machine learning or artificial intelligence algorithmto output a mapping to a target schema for a given input source schema.

Data added to the shares consumed by the consumer 404 and provider 402may then be operated on by the consumer 404 and provider 402,respectively, such as by executing queries against the data, aggregatingthe data, analyzing the data, or performing any other actions describedherein as being performed with respect to shares added to the consumedshares 156 of a user.

In particular embodiments, a data provider may improve its relationshipwith business partners by enabling the secure interchange of data in abi-directional manner, as discussed above. Traditional methods ofbi-directional data sharing have been challenging to accomplish, andonly very limited sets of data are shared via APIs, FTP, or filetransfer between companies. And this often comes at great cost, expense,data latency, and even some security risk.

A data provider may instead host a private data exchange, and invitetheir customers and partners to participate in the exchange. Customersand partners may access data in secure views, for example, and they mayalso push data in the other direction as well. This could be to sharedata back to the host, but also to potentially list data so that otherparticipants of the ecosystem can securely share it as well. Data from apublic data exchange, other private exchanges, or from other externalsources may also be included.

Every large company depends on other companies, and on its customers.Bidirectionally sharing data not only from the company to and from theseparties, but also between these external parties themselves, can allowrich, collaborative data ecosystems to develop where groups of companiescan work together around data. They can securely discover, combine, andenrich data assets to help service a common customer, or to form newpartnerships amongst themselves. Some of these relationships may evenlead to opportunities to sell data, secure views of or functions acrossdata to other participants of a walled garden ecosystem.

Referring to FIG. 7, the approach to sharing and consuming data asdescribed herein enables enrichment of data and return of that enricheddata to the exchange. For example, provider A may request 702 sharing ofdata (share 1) with the exchange in the same manner as for other methodsdescribed herein. The exchange manager 124 verifies, validates, and adds704 share 1 to the catalog 220.

A second provider B may then browse the catalog 220 and add 706 share 1to its consumed shares 156. Provider B may perform 708 operations on theshared data such as joining it with other data, performing aggregations,and/or performing other analysis with respect to share 1, resulting inmodified data (share 2). Provider B may then request 710 sharing ofshare 2 with the exchange as described herein. Note that the joining ofstep 708 may include joining any number of databases, such as any numberof shares based on any number of listings by any number of other users.Accordingly, iterations of steps 702-710 by many users may be viewed asa hierarchy in which a large number of listings 202 of multiple usersare narrowed down to a smaller number of listings 202 based on the datafrom the larger number of listings 202.

The exchange manager 124 verifies, validates, and adds 712 share 2 tothe catalog 220. This process may be repeated 714 with respect to share2, as provider A, provider B, or a different provider adds share 2,generates modified data based on it, and adds the result back to thecatalog in the same manner. In this manner, a rich ecosystem of data andanalysis may be made available to users. The shares according to themethod 700 may be any shares, point-to-point shares, private exchangeshares, or bi-directional exchange shares according to the methodsdisclosed herein.

In embodiments, the provider may perform steps 708 and 710 with respectto a listing 202 that is based on a listing 202. For example, listing L1of provider A is used by provider B to create listing L2, which is usedby provider C to create listing L3, which is used by provider A todefine listing L1. Such a flow could include any number of steps. Thismay be undesirable in some cases such that modification of listing L1 toreference L3 is not permitted in view L3 being derived from L1. In otherinstances, such a loop is permitted provided there is a time delay inwhen the data referenced by each listing is refreshed. For example, L1may reference L3 provided L3 will not be refreshed until some time afterL1 is refreshed and therefore the circular reference will not result incontinuous updating of L1 and L3 ad infinitum. Non-looping flows arealso contemplated by this disclosure, such that listing L1 is notinfluenced by other providers' use of listing L1

The listing created at step 712 (Share 2) may either (a) include copiesof the data from Share 1 remaining after step 708 and as modifiedaccording to step 708 or (b) include a view referencing Share 1 (e.g., adatabase created based on the listing 202 for Share 1 according to themethods disclosed herein) and defining the operations performed at step708 without including actual data from Share 1 or derived from Share 1.Accordingly, a hierarchy as described above may be a hierarchy of viewsthat either reference one or both of listing 202 that are views createdaccording to the method 700 or listing 202 of data from one or moreproviders according to any of the methods disclosed herein.

In the methods disclosed herein approaches are disclosed for creatingshares (listings 202) and for adding shares. In a like manner, aconsumer 404 may instruct the exchange manager 124 to remove addedshares. A provider 402 may instruct the exchange manager 124 to ceasesharing certain listings 202. In some embodiments, this may beaccompanied by actions to avoid disrupting consumers 404 of thoselistings 202. Such as by notifying these consumers 404 and ceasing toshare the listings 202 only after a specified time period after thenotification or after all consumers 404 have removed references to thelistings 202 from their consumed shares 156.

Use Cases

In a first use case a company implements a private exchange according tothe methods described above. In particular, listing 202 of the companyare viewable only by consumers 404 that are associated (employees,management, investors, etc.) with the company. Likewise, adding oflisting 202 is permitted only for those associated with the company.When adding a listing 202 to the consumed shares 156, it may be filteredbased on the identity of the consumer that adds it, i.e. data that isrelevant to the consumer's role within the company.

In a second use case, a provider 402 creates a reader or reader/writeraccount for a consumer 404 that is not yet a user of the virtualwarehouse 131. The account may be associated with the account data ofthe consumer (see consumer map of FIG. 4B discussed above). The consumer404 may then log on to that account and then access the provider'slistings to access the consumer's data 404 that is managed by theprovider 402 (see, e.g. discussion of FIG. 4A).

In a fifth use case a consumer 404 adds shares that are private (e.g.,accessible due to the identity of the consumer 404 according to themethods described above) and shares that are public. These may then bejoined by the consumer 404 and used to process queries.

In a sixth use case, a listing 202 may be shared base on a subscription(e.g., monthly) or be accessed based on per-query pricing, or a credituplift multiplier. Accordingly, the exchange manager 124 may manageprocessing of payment and access such that the consumer 404 is allowedto access the data subject to the pricing model (subscription, perquery, etc.).

In a seventh use case, the exchange manager 124 implements securefunctions and secure machine learning models (both training and scoring)that may be used to process private data such that the consumer 404 isallowed to use the result of the function or machine learning model butdoes not have access to the raw data processed by the function ormachine learning model. Likewise, the consumer of the shared data is notallowed to export the shared data. The consumer is nonetheless allowedto perform analytical functions with respect to the shared data. Forexample, the following secure function may be implemented to enableviewing of customer shopping data in a secure manner:

select 6139 as input_item, ss_item_sk as basket_Item, count(distinctss_ticket_number) baskets from udf_demo.public.sales wheress_ticket_number in (select ss_ticket_number from udf_demo.public.saleswhere ss_item_sk=6139) group by ss_item_sk order by 3 desc, 2;

In an eighth use case, the exchange manager 124 may provide usagestatistics of a listing 202 by one or more consumers 404 to the provider402 of the listing, e.g. queries, credits used, tables scanned, tableshit, etc.

In a ninth use case, the systems and methods disclosed herein are usedfor industry-specific applications. For example:

1. Cybersecurity

-   -   a. Allows for sharing of risk vectors, bad actors, IP        white/black lists, realtime attacks in progress, known good/bad        emailers, etc.

2. Healthcare

-   -   a. Secure sharing of patient information, including cost        information and outcome information, among other types of        information    -   b. Secure multi-hospital databases so patients can share their        information to multiple providers. (e.g., if patient A lives in        California and travels to Florida on vacation, is injured, and        is treated in an emergency room, the hospital in Florida may be        able to access patient A's records from disparate hospitals and        providers.)

Other industries may also benefit from private or public sharing of dataaccording to the systems and methods disclosed herein. Such as thefinancial services industry, telecommunications industry, media andadvertising industry, government agencies, militaries, and intelligenceagencies.

In a tenth use case, a first user provides marketing services for asecond user and, therefore, the second user shares a customer list withthe first user. The first user shares data regarding a marketingcampaign to the second user, such as campaign metadata, current userevents (session start/end for specific users, purchases for specificusers, etc.). This may be accomplished using the bi-directional sharingof FIG. 6. This data may be joined (customer list+customer events fromfirst user) in order to obtain a better understanding about events for aspecific user or groups of users. As noted above, this exchange of datamay be performed without creating copies or transferring data—each useraccesses the same copy of the shared data. Since no data is transferred,the data may be accessed in near real time as customer events occur.

FIG. 8A is a block diagram illustrating a network environment in which adata provider may share data via a cloud computing service. A dataprovider 810 may upload one or more data sets 820 in cloud storage usinga cloud computing service 112. These data sets may then become viewableby one or more data consumers 101-104. The data provider 810 may be ableto control, monitor, and increase the security of its data using thecloud computing service 112 using the methods and systems discussedherein. In particular embodiments, the data provider 810 may implement aprivate data exchange on its own online domain using the functionality,methods, and systems provided by cloud computing service 112. Dataproviders 810 may be any provider of data, such as retail companies,government agencies, polling agencies, non-profit organizations, etc.The data consumers 101-104 may be internal to the data provider 810 orexternal to the data provider 810. A data consumer that is internal tothe data provider may be an employee of the data provider. The dataprovider may be a bike-share company, which provides bicycles for adaily, monthly, annual, or trip-based fee. The bike share company maygather data about its users, such as basic demographic information aswell as ride information, including date of ride, time of ride, andduration of ride. This information may be available to employees of thebike share company via the cloud computing service 112.

The interaction between a data provider 810, private data exchange 812(as implemented by cloud computing service 112), and a data consumer maybe as follows. The data provider may create one or more listings 811using data sets 820. The listings may be for any suitable data. Forexample, a consumer data company may create a listing called “videostreaming” that contains data related to the video streaming habits of alarge number of users. The data provider may set listing policies 821related to who may view the listing 811, who may access the data in thelisting 811, or any other suitable policy. Such listing policies arediscussed above with reference to FIG. 2. The data provider 810 may thensubmit to the private exchange 812 at step 813. The private dataexchange 812 may be embedded inside a web domain of the data provider810. For example, if the web domain of the consumer data company iswww.entityA.com, the private data exchange may be found atwww.entityA.com/privatedataexchange. The private data exchange 812 mayreceive the listing and approve it at step 814 if the listing complieswith one or more rules as determined by the cloud computing service 112.The private data exchange 812 may then set up access controls at 815 atleast in part according to the listing policies what were set in step821. The private data exchange 812 may then invite members at step 816.The members may be data consumers 801. The data consumers 801 may acceptthe invitation at step 817 and then may begin consuming the data at 818.The type of data consumption may depend on the access controls that wereestablished at 815. For example, the data consumer may be able to readthe data only or share the data. As another example, a data consumer maybe able to do any combination of the above read, or share operations onthe data, subject to the access controls. In general, data sharing doesnot involve altering shared data.

In some embodiments, a data consumer 801 may independently access theprivate data exchange 812, either by directly navigating to the privatedata exchange 812 in a browser, or by clicking on an advertisement forthe private data exchange 812, or by any other suitable mechanism. Aprivate data exchange may also be rendered via custom or other code byaccessing listing and other information via an API. If the data consumer801 wishes to access the data within a listing and the listing is notalready universally available or the data consumer 801 does not alreadyhave access, the data consumer 801 may need to request access at step820. The data provider may approve or deny the request at 822. Ifapproved, the private data exchange may grant access to the listing at823. The user may then begin consuming the data as discussed above.

In particular embodiments, one or more data exchange administratoraccounts may be designated by the cloud computing service 112. The dataexchange administrator account may be an account associated with thedata exchange that facilitates the management of members of the privatedata exchange by designating members as data providers 810 or dataconsumers 801. The data exchange administrator account may facilitatethe control of listing visibility by enabling selection of which memberscan see a given listing. The data exchange administrator account mayalso have other functions such as approving listings before they arepublished on the private data exchange, track usage of each of thelistings, or any other suitable administrative function. In someembodiments, the data exchange owner, the data provider, and the dataexchange administrator account are part of the same entity; in someembodiments, they are separate entities. A data provider may createlistings, may test sample queries on the data underlying a listing, mayset listing access, grant access to listing requests, and track usage ofeach of the listings and the data underlying the listings. In someembodiments, the data exchange administrator account may grant or denylisting requests (e.g., publish requests or access requests) instead ofthe data provider. A data consumer 801 may visit a private data exchangeand browse visible listings which may appear as tiles. To consume thedata underlying a listing, the consumer may either immediately accessthe data, or may request access to the data.

FIG. 8B is a block diagram illustrating a part of the networkenvironment of FIG. 8A in which the exchange administrator 830 maymanage membership of the private data exchange 812. At block 835, theexchange administrator 830 may add a new member to the private dataexchange 812. In some embodiments, the exchange administrator 830 mayadd the new member 831 by inviting the member in any suitable manner.For example, the exchange administrator 830 may send an invite to a useraccount 831 of the cloud computing service 112, or by sending an emailto an email address associated with the user account 831 (hereinafter“account 831”) on the cloud computing service 112, for example. A userof the account 831 may accept the invitation at block 837, thus becomingthe new member, and at block 839 the exchange administrator 830 mayassign the new member an account type. The account type may comprise atleast one of the exchange admin type, provider type, or consumer type.Each of the exchange admin type, provider type, and consumer type may beassociated with one or more rights for interacting with listings on theprivate data exchange 812. For example, each of the exchange admin,provider, and consumer types may be associated with one or more rightsfor viewing and accessing listings on the private data exchange 812. Inaddition, each of the provider and exchange admin types may be furtherassociated with rights for creating new listings as well as otherfunctions as discussed in further detail herein. For example, a dataconsumer may view the listings of the private data exchange 812 as wellas view and access the underlying data of each listing (subject to thevisibility and access rules for each listing), but may not publishlistings. A member who is both a data consumer and a data provider mayview the listings of the private data exchange 812 as well as view andaccess the underlying data of each listing (subject to the visibilityand access rules for each listing), and may also publish listings(subject to approval by the exchange administrator 830 in someembodiments). Accessing the underlying data of a listing may includeperforming SQL queries on the underlying data including databaseoperations such as joins, aggregation, and other analysis, for example.A member who is an exchange administrator, such as exchangeadministrator 830, may do everything a data provider and a data consumercan do, as well as manage members (e.g., add members, remove members,change member roles), access a list of member accounts, and editmetadata associated with the data exchange 812, as discussed in furtherdetail herein. In some embodiments, in addition to managing members,accessing a list of member accounts, and editing metadata associatedwith the data exchange 812, an exchange administrator may have all therights associated with either the provider or consumer account types ormay not have any of the rights associated with the provider and consumeraccount types. The account type assigned to the new member by theexchange administrator 830 may comprise one or more of the consumer,provider, and exchange administrator types. For example, the exchangeadministrator 830 may designate the new member as both a consumer and aprovider, and thus the new member may have a set of rights that includeviewing the listings of the private data exchange 812, viewing andaccessing the underlying data of each listing (subject to the visibilityand access rules for each listing), and also publishing listings(subject to approval by the exchange administrator 830 in someembodiments).

In particular embodiments, at block 841, the exchange administrator 830may modify the new member's viewing and access rights for one or morelistings based on the visibility and access rules of each of thelistings of the private data exchange 812. The visibility and accessrules for a listing may be based on the listing policy set by the memberwho created the listing. The listing policy may be based on, forexample, access controls 206 and filters 208 set by the member asdiscussed further in FIG. 2.

For example, (also referring to FIG. 2) the visibility and access rulesfor a listing 202 may define specific user identifiers 214 of membersthat may view references to the listing 202 when browsing the catalog220. The visibility and access rules may define a class of members(members of a certain profession, members associated with a particularcompany or organization, members within a particular geographical areaor country) that may view references to the listing 202 when browsingthe catalog 220. In some embodiments, an excluded member that isexcluded from accessing a listing 202 may still be permitted to view arepresentation of the listing when browsing the catalog 220 and mayfurther be permitted to request access to the listing 202 as discussedbelow. The exchange administrator 830 may then review the request foraccess to the listing and may choose to modify the visibility and accessrules to permit access to excluded members or classes of excludedmembers (e.g., members in excluded geographic regions or countries).

The visibility and access rules may further define specific portions ofdata of a listing 202 that may be viewed and accessed by a particularmember or class of members. In particular, the visibility and accessrules may indicate that a member that selects a listing 202 to add tothe consumed shares 156 of the member is permitted to access the datareferenced by the listing but only a filtered version that only includesdata associated with the identifier 214 of that member, associated withthat member's organization, or specific to some other classification ofthe member.

In other examples, the visibility and access rules may also specifywhether the data referenced by a listing is exportable by the consumer.In addition, the visibility and access rules may specify what types ofdatabase operations can be performed on the data of the listing, or mayspecify restrictions on operations performed on the data of the listing.For example, the visibility and access rules may specify that a securejoin may be performed such that analysis may be performed with respectto shared data but the actual shared data is not accessible by a dataconsumer (e.g., recipient of the share).

At block 843, the exchange administrator 830 may also remove existingmembers from the private data exchange 812 and edit metadata associatedwith the private data exchange 812. In some embodiments, if the exchangeadministrator 830 removes a member or changes a member's type fromprovider to a consumer for example, then at block 845 existing listingspublished by that member may become unpublished from the private dataexchange 812. Additionally, existing shares added to the private dataexchange 812 by the member are no longer considered part of the privatedata exchange 812. The listings published by that member may bearchived, and are no longer visible in the UI to anyone, including themember. The cloud computing service 112 can un-archive this if the samemember (e.g., same user account on the cloud computing service 112) whohas been removed is made a provider again.

The exchange administrator 830 may also further modify the set of rightsof a member in response to the visibility and access rules for a listingchanging. For example, if a data provider changes the visibility andaccess rules for a listing they created to include members of apreviously excluded class of members, then exchange administrator 830may ensure that the set of rights of each member of that class isupdated to reflect the change.

FIG. 9 is an example private data exchange 900 in accordance with anembodiment of the present invention. Private data exchange 900 may bewhat a data consumer sees when she navigates to the private dataexchange on the web. For example, the data consumer may enterwww.entityA.com/privatedataexchange in her browser. As discussed herein,“Entity A Data Exchange” may be a private data exchange that isfacilitated by the cloud computing service 112 and is embedded intoEntity A's own web domain or into an application, or may be accessed viaan API. Private data exchange 900 may include several listings fordifferent data sets, for example listings A-L. The listing A-L may alsobe referred to herein as a data catalog, which may allow visitors to theprivate data exchange to view all the available listings in the privatedata exchange. These listings may be placed by an administrator accountinternal to Entity A. Providing a data catalog in this manner may serveto combine the benefits of crowdsourced content, data quality, and theright level of centralized control and coordination that can overcomethe challenges that have slowed the adoption of other approaches toenterprise data cataloging (e.g., indexing and crawling systems). Itallows users across an enterprise to contribute data, use data fromother groups, and join data together to create enriched data products,for both internal use as well as potentially for external monetization.

As an example and not by way of limitation, Entity A may be a datacollection company that has collected and analyzed the consuming habitsof millions of individuals in several different categories. Their datasets may include data in the following categories: online shopping,video streaming, electricity consumption, automobile usage, internetusage, clothing purchases, mobile application purchases, clubmemberships, and online subscription services. Each of these data setsmay correspond to different listings. For example, Listing A may be foronline shopping data, Listing B may be for video streaming data, ListingC may be for electricity consumption data, and so on. Note that the datamay be anonymized so that individual identities are not revealed. Thelistings located below line 915 may correspond to third-party listingsthat entity A may allow on its private data exchange. Such listings maybe generated by other data providers and may be subject to approval byEntity A before being added to the private data exchange 900. A dataconsumer may click on and view any of the listings subject to variousaccess controls and policies as discussed above with reference to FIGS.2, 4, and 8.

In particular embodiments, a data provider may invite members to accessits private data exchange, as discussed with reference to FIG. 8. Oneclass of members may be the physical and digital supply chain suppliersof the data provider. For example, a data provider may share data withsuppliers on its inventory levels or consumption of things provided bythe suppliers, so they can better meet the needs of the data provider.In addition, digital data providers may provide data directly into itsprivate data exchange, to make it immediately usable and joinable to theinternal enterprise data, saving costs for both parties on transmitting,storing, and loading the data.

Some companies such as hedge funds and marketing agencies bring in datafrom many external sources. Some hedge funds evaluate hundreds ofpotential data sets per year. A private data exchange may be used to notonly connect with data that has already been purchased, but can also beused to evaluate new data assets. For example, a hedge fund could havepotential data suppliers list their data on their private exchange, andthe fund could explore and “shop” for data in a private data store wherethey are the only customer. Such an internal data store could also“tunnel” in data assets from a public Data Exchange (e.g., the SNOWFLAKEpublic Data Exchange), as discussed with reference to FIG. 11.

As another example, an existing provider of marketing data to a companycould list some additional datasets that their customer could use viatheir private exchange on a trial basis, and if the customer finds themuseful, the supplier can immediately provide full access through thesame exchange. These arrangements can bring much greater depth of data,bi-directional and much fresher data, and greater trust and transparencyto relationships between suppliers of data and physical goods and theircustomers.

FIG. 10 is a diagram illustrating an example secure view of shared datafrom a private data exchange. When a data consumer 1020 wishes to accessdata in a listing (e.g., Listing H), the cloud computing service 112 mayfacilitate access via a secure view of shared data 1010. The secure viewof shared data 1010 may include metadata 1015 that includes the metadataand access controls discussed herein with reference to FIG. 2. This mayallow data providers to share data without exposing the underlyingtables or internal details. This makes the data more private and secure.With a secure view of shared data 1010, the view definition and detailsare only visible to authorized users.

In a private data exchange, data may be shared both within the sameentity and between different entities. Additionally, the data sharingmay be one-way, two-way, or multi-way. This leads to five main use-casesfor sharing data: two-way inter-entity, two-way intra-entity, one-wayinter-entity, one-way intra-entity, and multi-way multi-entity. Anexample of two-way inter-entity data sharing may be data sharing fromportfolio companies to a parent company and between portfolio companies.An example of two-way intra entity data sharing may be data sharing fromthe headquarters of a large company to the different business unitswithin that company, and also data sharing from the business units toheadquarters. An example of one-way inter-entity data sharing may be alarge data provider (e.g., a national weather service) that shares datawith lots of different entities, but does not receive data from thoseentities. An example of one-way intra-entity may be a large company thatprovides data to its respective business units but does not receive datafrom those business units. In particular embodiments, data may be sharedas “point-to-point shares” of specific data, or as “any-shares”. Apoint-to-point share of specific data may include a private dataexchange share between a parent company and specific portfoliocompanies. An any-share may include a private data exchange share from aparent company to a broad group of data consumers on a public or withina private exchange.

In particular embodiments, the cloud computing service 112 may generatea private data exchange for an entity who is the owner of the data to beshared on the private data exchange. The cloud computing service 112 maydesignate one or more administrator accounts of the private dataexchange. These administrator accounts may have control over the accessrights of the private data exchange with regard to other users. Forexample, an administrator account may facilitate the addition of anotheruser account to the private data exchange and designation of thataccount as a data provider, data consumer, exchange administrator, or acombination of these.

In particular embodiments, the exchange administrator account mayfacilitate and control viewing and access rights to the private dataexchange. Viewing rights may include a list of entities that may viewthe listing in the private data exchange. Access rights may include alist of entities that may access the data after selecting a particularlisting. For example, a company may publish private data exchange 900and may include several listings, Listing A through Listing L. Each ofthese listings may include their own individual viewing and accessrights. For example, Listing A may include a first list of entities thathave rights to view the listing on the private data exchange 900 and asecond list of entities that have rights to access the listing. Viewinga listing may simply be to see that the listing exists on the privatedata exchange. Accessing a listing may be to select the listing andaccess the underlying data for that listing. Access may include bothviewing the underlying data, manipulating that data, or both.Controlling viewing rights may be useful for data providers who do notwant some users to even know that a certain listing exists on theprivate data exchange. Thus, when a user who does not have viewingrights to a particular listing visits the private data exchange, thatuser will not even see the listing on the exchange.

In particular embodiments, the above discussed viewing and access rightsmay be provisioned via an application program interface (API). Theexchange catalog may be queries and updated via the API. This may allowa data provider to show listings on its own application or website toanyone who visits. When a user wants to access or request access todata, the user may then create an account with the cloud computingservice 112 and obtain access. In some embodiments, a URL may be calledwith a user requests access to data within a listing. This may allow forintegration with external request approval workflows. For example, if auser makes an access request, an external request approval workflow ofthe data provider may be accessed and activated. The external requestapproval workflow may then operate normally to perform an externalrequest approval process. In some embodiments, a listing may beunlisted, which means that the listing exists but is not visible on thedata exchange. To access an unlisted listing, a consumer may input aglobal URL into the browser. This may require a unique URL for eachlisting.

In particular embodiments, when a new private data exchange is createdfor a data provider, the cloud computing service 112 may designate adata exchange administrator account, and may also generate the followingmetadata about the private data exchange: the name of the private dataexchange, which needs to be unique, a display name, a logo, a shortdescription of the private data exchange, and an indication of whetherapproval from the exchange administrator account is necessary forpublishing (e.g., Admin Approval for Publishing). This may be atrue/false statement. It may be set to true if the exchangeadministrator account needs to approve listings submitted to the privatedata exchange before they are published. It may be set to false if theexchange administrator account does not need to provide such approval.In this case, providers can publish data directly. If the exchangeadministrator account sets the Admin Approval for Publishing to True,the exchange administrator account may be able to see a list ofListings, and select a listing to preview and approve/reject. The ownerof the private data exchange may be the account that is paying for theprivate data exchange. This metadata information may be stored as partof an Exchange object. Also stored in association with the private dataexchange may be the users and accounts who provide data to the exchange,the consumers of the exchange, and the exchange admin(s).

In particular embodiments, the exchange administrator account may addmembers (e.g., data providers and data consumers) to the private dataexchange by inviting the members in any suitable manner. For example, byinviting the users' accounts on the cloud computing service 112, or bysending an email to the users' email account addresses. When theexchange administrator account adds a member to the private dataexchange, the exchange administrator account may also specify themember-type: exchange admin, provider, or consumer. An exchangeadministrator account may be able to add and remove members from theprivate data exchange and to edit metadata associated with the privatedata exchange. For each user, the exchange administrator account maydesignate whether the user is an exchange admin, a data provider, and adata consumer. The following table summarizes the rights associated witheach type of account.

TABLE 1 Rights Associated with Each Type of Private Data ExchangeAccount is_Exchange_Admin is_Data_Provider is_Data_Consumer DescriptionFalse False True Can Discover & Consume listings (subject to Listingvisibility and access rules), but cannot publish listings False TrueTrue Can Discover & Consume listings (subject to Listing visibility andaccess rules), plus can publish listings False True False Can publishlistings, but when they go to the consumer view they only see their ownlistings. They will not be able to ‘get’ their own listing as they willget a self-sharing prohibited error. True True True Can do everything adata provider and a data consumer can do, as well as add members, removemembers, change member roles, access list of member accounts, and editmetadata.

In some embodiments, if the exchange administrator account removes amember or changes a member's type from provider to a consumer only, thenexisting listings published by that member may become unpublished fromthe Exchange. Additionally, existing shares added to the Exchange by themember are no longer considered part of the private data exchange. Thelistings published by that member may be archived, and are no longervisible in the UI to anyone, including the member. The cloud computingservice 112 can un-archive this if the same member (same account on thecloud computing service 112) who has been removed is made a Provideragain.

In some embodiments, the exchange administrator account may be able tospecify a list of categories as well as edit an existing list.Categories may have icons associated with them, and the exchangeadministrator account may be able to specify the icon along with thecategory name.

When a member becomes a data provider, a provider profile may begenerated that includes a logo, a description of the provider, and a URLto the provider's website. When submitting listings, a provider may dothe following: select which private data exchange to publish the data in(e.g., many private exchanges may exist and the provider may need toselect a subset of these exchanges, which may be one or more), and setmetadata about the new listing. The metadata may include a listingtitle, a listing type (e.g., Standard or Personalized), a listingdescription, one or more usage examples (e.g., title and samplequeries), a listing category, which may be input as free form text, anupdate frequency for the listing, a support email/URL, and adocumentation link. The provider may also set access for the listing.The provider may allow the exchange administrator account to control thevisibility of the listing, or the provider may retain that control foritself. The provider may also associate a share with a listing. For astandard share, a listing may be associated with zero or more shares.The provider may associate shares to a listing through the UI or SQL.For personalized shares, when the provider provisions a share inresponse to a request, the provider may associate that share with thelisting. When the provider wishes to publish the listing, the listingmay first need approval from the exchange admin, depending on thepublishing rules of the private data exchange.

FIG. 11 is a diagram illustrating an example tunneling of a data listingbetween a public data exchange and a private data exchange.Alternatively, data may be tunneled between two public data exchanges orbetween two private data exchanges, or from one public exchange tomultiple private exchanges, or any other suitable combination. In someembodiments, an entity may wish to offer a publicly listed data listingon its private data exchange. For example, Entity B may wish to includeListing F of public data exchange 1100 on its own private data exchange1000. The data underlying Listing F may be tunneled from public dataexchange 1100 to private data exchange 1000. In particular embodiments,data may be tunneled between two private data exchanges. At times, afirst data provider may wish to allow a second data provider to listdata belonging to the first data provider on a private data exchange ofthe second data provider. Tunneling of data listings may allow the twodata providers to offer the same listing. As an example, Entity A andEntity B may have a business agreement to share listing F on each oftheir private data exchanges. Listing F may be the property of Entity A,but Entity B may have a license to offer it on its private data exchangeas well. In this case, both of the listings titled “Listing F” willpoint to the same data set stored in cloud computing platform 110. Thetunnel 1015 is a representation to illustrate that Listing F may beshared securely and easily between two or more data exchanges 1100 and1000. No data is copied or transferred in the tunneling. Instead, eachlisting contains a pointer to the data referenced by Listing F asdiscussed herein.

In particular embodiments, tunnel linking may be accomplished between aprivate data exchange and a public data exchange, or vice versa. Forinstance, data exchange 1100 may be a public data exchange. Entity B mayuse a listing listed on the public data exchange 1100 on its own privatedata exchange 1000 via tunnel 1015. In some embodiments, a data listingmay be tunneled from one data exchange to another data exchange and thenthe underlying data may be joined with another data set, and then a newlisting may be generated from the combined data set. As an example andnot by way of limitation, a first data set may be listed on a privatedata exchange that includes NBA player shooting statistics over the lastfive years. A second data set may be listed on a different data exchangethat includes weather data over the same time span. These two data setsmay be joined and listed as a new listing in either a private or apublic data exchange. Data consumers may then access this data set,subject to the viewing and access controls discussed herein, to gaininsight into how the weather might affect player shooting percentages.Additionally, if data is listed on a public data exchange (e.g., a dataexchange hosted by the cloud computing service 112), this data may betunneled to a private data exchange.

In some embodiments, tunneling of datasets may be used to create an“industry-wide” data exchange that is either public or private. Manydifferent entities may tunnel datasets to a “mega ecosystem dataexchange.” If a private ecosystem data exchange really takes off, itcould become so big and influential that it could become the standardplace for a whole industry to interchange, collaborate around, andmonetize data. There is probably room for one or two “mega ecosystemdata exchanges” in each industry. Once any one gains significanttraction, it could become the “go to” place for that industry. If morethan one viable exchange emerges in an industry, the respective hosts ofthese could decide to partner and “cross-tunnel” some (but maybe notall) assets between their exchanges to get critical mass.

While it is possible that industry coalitions could host such exchangesvia tunneling, it may be more likely that one or two large players ineach industry will bootstrap ecosystem private data exchanges fast andbroadly enough to become the de facto data exchange for their industry.This provides a significant incentive for companies that want to becomemajor players in the data side of their industries to start as soon asthey can to build their internal data exchanges and then open them upquickly to their suppliers, customers, and partners.

FIG. 12 is a diagram illustrating an example data query and deliveryservice 1200 according to some embodiments of the invention. Data queryand delivery service 1200 illustrates four ways a data provider may beable to share data. The first way is through a data exchange 900. Thedata exchange 900 may be a public data exchange or a private dataexchange. The data provider 1210 may list 1211 the data on the dataexchange according to the methods and systems described herein withreference to FIGS. 2, 4, and 8. The data consumer 1220 may access thedata in the listings by either accepting an invitation from the dataprovider as discussed herein or by requesting 1212 access to the listingas discussed herein with reference to FIG. 8. The second way data may beshared is by directly sharing the data at 1213. This may be apoint-to-point share as discussed with reference to FIG. 4, or may beany other suitable type of share, accomplished using the secure datashare methods discussed herein. Note that the data provider 1210 and thedata consumer 1220 are both users of the cloud computing service 112. Ifthe data provider 1210 wishes to share data with a non-user 1230, thisis possible as a third way to share the data, with a reader account 1215a or with a reader/writer account 1215 b. Here the non-user may need tohave a reader account but may not need to be an actual user of the cloudcomputing service 112. A reader account may allow the non-user 1230 toview the data but do nothing else to the data. Finally, a fourth way toshare data is via a file drop to cloud storage 1214. Here the dataprovider 1210 may make a copy of a data set 1216 and may allow foranother non-user 1230 to have the data set 1216. This way of sharingdata may not allow the data provider 1210 to retain control of the dataset. Thus, using the fourth way, the non-user 1230 may be able to view,manipulate, and re-share the data.

FIG. 13 is a block diagram illustrating an example method 1300A forproviding a private data exchange. In general, the method 1300 may beperformed by processing logic that may include hardware (e.g.,processing device, circuitry, dedicated logic, programmable logic,microcode, hardware of a device, integrated circuit, etc.), software(e.g., instructions run or executed on a processing device), or acombination thereof. For example, the processing logic may beimplemented as exchange manager 124. Method 1300 may begin at step 1310,where the processing logic provides a data exchange on behalf of anentity. The data exchange may include a plurality of data listingsprovided by one or more data providers. The data listings may referenceone or more data sets stored in a data storage platform associated withthe cloud computing service. At step 1320, the processing logic maydesignate a data exchange administrator account of the data exchange,wherein the data exchange administrator account is associated with theentity and is capable of: (1) granting and denying requests from dataconsumers to access the data exchange; and (2) granting and denyingrequests from data providers to publish data listings on the dataexchange. At step 1330, the processing logic may receive a request froma data provider to publish a data listing on the data exchange. The dataprovider may be any suitable data provider as discussed herein. At step1340, the processing logic may route the request to the data exchangeadministrator account. This may be because the processing logic that isassociated with the cloud computing service 112 may not make thedecision on whether a data provider may or may not publish a datalisting on the data exchange. This decision may be reserved for the dataexchange administrator account, who is either the owner of the privatedata exchange or associated with the owner of the private data exchange.

At step 1350, the processing logic may receive an authorizationindication from the data exchange administrator account approving therequest to publish the data listing. At step 1360, the processing logicmay publish the data listing on the data exchange. Publishing the datalisting may allow at least one data consumer to view or access the datalisting within the data exchange. In embodiments, viewing a data listingmay allow the data consumer to view the data referenced by the listing.In embodiments, accessing a data listing may allow a data consumer toview the data referenced by the listing and to run queries on that data.The data exchange administrator account may be able to specify whether apublished data listing is viewable only, or viewable and accessible, aswell as which data consumers may view only and which data consumers mayview and access the data listing. In embodiments, accessible may meanthat a data consumer may run queries against the data referenced by thedata listing.

FIG. 13B is a block diagram illustrating an example method 1300B forproviding a private data exchange. Method 1300B may be an extension of1300A or may be a stand-alone method. Method 1300B may be performed bythe same processing logic as the processing logic that performs method1300A. Method 1300B may begin at step 1302, where the processing logicreceives a request from a user to access the data exchange, wherein theuser has not been previously approved to access the data exchange. Atstep 1304, the processing logic routes the request to the data exchangeadministrator account. At step 1306, the processing logic receives anauthorization indication from the data exchange administrator accountapproving the request to access the data exchange. At step 1308, theprocessing logic grants the user access to the data exchange. Inembodiments, granting the user access to the data exchange may includeenabling the user to view and run queries against data referenced by afirst data listing but not against a second data listing. For example,the user may be enabled to view and run queries against data referencedby Listing A but not against data referenced by Listing B.

FIG. 14 is a block diagram of an example computing device 1400 that mayperform one or more of the operations described herein, in accordancewith some embodiments. Computing device 1400 may be connected to othercomputing devices in a LAN, an intranet, an extranet, and/or theInternet in either a public or private network. The computing device mayoperate in the capacity of a server machine in client-server networkenvironment or in the capacity of a client in a peer-to-peer networkenvironment. The computing device may be provided by a personal computer(PC), a set-top box (STB), a server, a network router, switch or bridge,or any machine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while only a single computing device is illustrated, the term “computingdevice” shall also be taken to include any collection of computingdevices that individually or jointly execute a set (or multiple sets) ofinstructions to perform the methods discussed herein.

The example computing device 1400 may include a processing device (e.g.,a general purpose processor, a PLD, etc.) 1402, a main memory 1404(e.g., synchronous dynamic random access memory (DRAM), read-only memory(ROM)), a static memory 1406 (e.g., flash memory and a data storagedevice 1418), which may communicate with each other via a bus 1430.

Processing device 1402 may be provided by one or more general-purposeprocessing devices such as a microprocessor, central processing unit, orthe like. In an illustrative example, processing device 1402 maycomprise a complex instruction set computing (CISC) microprocessor,reduced instruction set computing (RISC) microprocessor, very longinstruction word (VLIW) microprocessor, or a processor implementingother instruction sets or processors implementing a combination ofinstruction sets. Processing device 1402 may also comprise one or morespecial-purpose processing devices such as an application specificintegrated circuit (ASIC), a field programmable gate array (FPGA), adigital signal processor (DSP), network processor, or the like. Theprocessing device 1402 may be configured to execute the operationsdescribed herein, in accordance with one or more aspects of the presentdisclosure, for performing the operations and steps discussed herein. Inone embodiment, processing device 1402 represents cloud computingplatform 110 of FIG. 1. In another embodiment, processing device 1402represents a processing device of a client device (e.g., client devices101-104).

Computing device 1400 may further include a network interface device1408 which may communicate with a network 1420. The computing device1400 also may include a video display unit 1410 (e.g., a liquid crystaldisplay (LCD) or a cathode ray tube (CRT)), an alphanumeric input device1412 (e.g., a keyboard), a cursor control device 1414 (e.g., a mouse)and an acoustic signal generation device 1416 (e.g., a speaker). In oneembodiment, video display unit 1410, alphanumeric input device 1412, andcursor control device 1414 may be combined into a single component ordevice (e.g., an LCD touch screen).

Data storage device 1418 may include a computer-readable storage medium1428 on which may be stored one or more sets of instructions, e.g.,instructions for carrying out the operations described herein, inaccordance with one or more aspects of the present disclosure. Privatedata exchange instructions 1426 may also reside, completely or at leastpartially, within main memory 1404 and/or within processing device 1402during execution thereof by computing device 1400, main memory 1404 andprocessing device 1402 also constituting computer-readable media. Theinstructions may further be transmitted or received over a network 1420via network interface device 1408.

While computer-readable storage medium 1428 is shown in an illustrativeexample to be a single medium, the term “computer-readable storagemedium” should be taken to include a single medium or multiple media(e.g., a centralized or distributed database and/or associated cachesand servers) that store the one or more sets of instructions. The term“computer-readable storage medium” shall also be taken to include anymedium that is capable of storing, encoding or carrying a set ofinstructions for execution by the machine and that cause the machine toperform the methods described herein. The term “computer-readablestorage medium” shall accordingly be taken to include, but not belimited to, solid-state memories, optical media and magnetic media.

Unless specifically stated otherwise, terms such as “receiving,”“routing,” “granting,” “determining,” “publishing,” “providing,”“designating,” “encoding,” or the like, refer to actions and processesperformed or implemented by computing devices that manipulates andtransforms data represented as physical (electronic) quantities withinthe computing device's registers and memories into other data similarlyrepresented as physical quantities within the computing device memoriesor registers or other such information storage, transmission or displaydevices. Also, the terms “first,” “second,” “third,” “fourth,” etc., asused herein are meant as labels to distinguish among different elementsand may not necessarily have an ordinal meaning according to theirnumerical designation.

Examples described herein also relate to an apparatus for performing theoperations described herein. This apparatus may be specially constructedfor the required purposes, or it may comprise a general purposecomputing device selectively programmed by a computer program stored inthe computing device. Such a computer program may be stored in acomputer-readable non-transitory storage medium.

The methods and illustrative examples described herein are notinherently related to any particular computer or other apparatus.Various general purpose systems may be used in accordance with theteachings described herein, or it may prove convenient to construct morespecialized apparatus to perform the required method steps. The requiredstructure for a variety of these systems will appear as set forth in thedescription above.

The above description is intended to be illustrative, and notrestrictive. Although the present disclosure has been described withreferences to specific illustrative examples, it will be recognized thatthe present disclosure is not limited to the examples described. Thescope of the disclosure should be determined with reference to thefollowing claims, along with the full scope of equivalents to which theclaims are entitled.

As used herein, the singular forms “a”, “an” and “the” are intended toinclude the plural forms as well, unless the context clearly indicatesotherwise. It will be further understood that the terms “comprises”,“comprising”, “includes”, and/or “including”, when used herein, specifythe presence of stated features, integers, steps, operations, elements,and/or components, but do not preclude the presence or addition of oneor more other features, integers, steps, operations, elements,components, and/or groups thereof. Therefore, the terminology usedherein is for the purpose of describing particular embodiments only andis not intended to be limiting.

It should also be noted that in some alternative implementations, thefunctions/acts noted may occur out of the order noted in the figures.For example, two figures shown in succession may in fact be executedsubstantially concurrently or may sometimes be executed in the reverseorder, depending upon the functionality/acts involved.

Although the method operations were described in a specific order, itshould be understood that other operations may be performed in betweendescribed operations, described operations may be adjusted so that theyoccur at slightly different times or the described operations may bedistributed in a system which allows the occurrence of the processingoperations at various intervals associated with the processing.

Various units, circuits, or other components may be described or claimedas “configured to” or “configurable to” perform a task or tasks. In suchcontexts, the phrase “configured to” or “configurable to” is used toconnote structure by indicating that the units/circuits/componentsinclude structure (e.g., circuitry) that performs the task or tasksduring operation. As such, the unit/circuit/component can be said to beconfigured to perform the task, or configurable to perform the task,even when the specified unit/circuit/component is not currentlyoperational (e.g., is not on). The units/circuits/components used withthe “configured to” or “configurable to” language include hardware—forexample, circuits, memory storing program instructions executable toimplement the operation, etc. Reciting that a unit/circuit/component is“configured to” perform one or more tasks, or is “configurable to”perform one or more tasks, is expressly intended not to invoke 35 U.S.C.112, sixth paragraph, for that unit/circuit/component. Additionally,“configured to” or “configurable to” can include generic structure(e.g., generic circuitry) that is manipulated by software and/orfirmware (e.g., an FPGA or a general-purpose processor executingsoftware) to operate in manner that is capable of performing the task(s)at issue. “Configured to” may also include adapting a manufacturingprocess (e.g., a semiconductor fabrication facility) to fabricatedevices (e.g., integrated circuits) that are adapted to implement orperform one or more tasks. “Configurable to” is expressly intended notto apply to blank media, an unprogrammed processor or unprogrammedgeneric computer, or an unprogrammed programmable logic device,programmable gate array, or other unprogrammed device, unlessaccompanied by programmed media that confers the ability to theunprogrammed device to be configured to perform the disclosedfunction(s).

Any combination of one or more computer-usable or computer-readablemedia may be utilized. For example, a computer-readable medium mayinclude one or more of a portable computer diskette, a hard disk, arandom access memory (RAM) device, a read-only memory (ROM) device, anerasable programmable read-only memory (EPROM or Flash memory) device, aportable compact disc read-only memory (CDROM), an optical storagedevice, and a magnetic storage device. Computer program code forcarrying out operations of the present disclosure may be written in anycombination of one or more programming languages. Such code may becompiled from source code to computer-readable assembly language ormachine code suitable for the device or computer on which the code willbe executed.

Embodiments may also be implemented in cloud computing environments. Inthis description and the following claims, “cloud computing” may bedefined as a model for enabling ubiquitous, convenient, on-demandnetwork access to a shared pool of configurable computing resources(e.g., networks, servers, storage, applications, and services) that canbe rapidly provisioned (including via virtualization) and released withminimal management effort or service provider interaction and thenscaled accordingly. A cloud model can be composed of variouscharacteristics (e.g., on-demand self-service, broad network access,resource pooling, rapid elasticity, and measured service), servicemodels (e.g., Software as a Service (“SaaS”), Platform as a Service(“PaaS”), and Infrastructure as a Service (“IaaS”)), and deploymentmodels (e.g., private cloud, community cloud, public cloud, and hybridcloud).

The flow diagrams and block diagrams in the attached figures illustratethe architecture, functionality, and operation of possibleimplementations of systems, methods, and computer program productsaccording to various embodiments of the present disclosure. In thisregard, each block in the flow diagrams or block diagrams may representa module, segment, or portion of code, which comprises one or moreexecutable instructions for implementing the specified logicalfunction(s). It will also be noted that each block of the block diagramsor flow diagrams, and combinations of blocks in the block diagrams orflow diagrams, may be implemented by special purpose hardware-basedsystems that perform the specified functions or acts, or combinations ofspecial purpose hardware and computer instructions. These computerprogram instructions may also be stored in a computer-readable mediumthat can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable medium produce an article of manufactureincluding instruction means which implement the function/act specifiedin the flow diagram and/or block diagram block or blocks.

The foregoing description, for the purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theembodiments were chosen and described in order to best explain theprinciples of the embodiments and its practical applications, to therebyenable others skilled in the art to best utilize the embodiments andvarious modifications as may be suited to the particular usecontemplated. Accordingly, the present embodiments are to be consideredas illustrative and not restrictive, and the invention is not to belimited to the details given herein, but may be modified within thescope and equivalents of the appended claims.

What is claimed is:
 1. A method comprising: adding a new member to adata exchange, wherein the data exchange comprises a set of listings;assigning an account type to the new member, wherein the account type isassociated with one or more rights with respect to the set of listingssuch that the new member has a set of rights based on the account type;and modifying, by a processing device, the set of rights of the newmember with respect to a listing from the set of listings based on a setof visibility and access rules for the listing, wherein the new memberdirects queries for data of the listing to a reference database having aportion of the data of the listing that is filtered based on the set ofvisibility and access rules for the listing.
 2. The method of claim 1,wherein the account type is one of a plurality of account types, theplurality of account types comprising a consumer type, a provider type,and an exchange administrator type, and wherein each of the plurality ofaccount types is associated with one or more rights with respect to theset of listings.
 3. The method of claim 2, wherein the account typecomprises the consumer type, the one or more rights associated with theconsumer type comprising rights to: view each listing in the set oflistings, view the data of each listing in the set of listings, andaccess the data of each listing in the set of listings.
 4. The method ofclaim 1, wherein the set of visibility and access rules for the listingcomprises rules for: filtering members of the data exchange who can viewthe listing, filtering members of the data exchange who can view data ofthe listing, filtering members of the data exchange who can manipulatethe data of the listing, and filtering the data of the listing thatparticular members of the data exchange can access.
 5. The method ofclaim 4, wherein modifying the set of rights of the new member withrespect to the listing comprises: restricting the new member fromviewing the listing based on the set of visibility and access rules forthe listing.
 6. The method of claim 4, wherein modifying the set ofrights of the new member with respect to the listing comprises:filtering the portion of the data of the listing based on the set ofvisibility and access rules for the listing, the portion of the data ofthe listing comprising data the new member can access; and granting thenew member access to the portion while restricting the new member fromaccess to remaining portions of the data of the listing by including theportion of the data of the listing in the reference database.
 7. Themethod of claim 6, wherein granting the new member access to thedetermined portions further comprises: adding a reference to thereference database to an account of the new member.
 8. The method ofclaim 3, wherein the account type further comprises the provider type,the one or more rights associated with the provider type comprisingrights to: create new listings in the set of listings, test samplequeries on data of each of the set of listings, set access policies foreach of the set of listings, grant requests to access each of the set oflistings, and track usage of each of the set of listings and usage ofdata of each of the set of listings.
 9. The method of claim 1, furthercomprising: removing an existing member from the data exchange; andunpublishing each listing of the set of listings created by the existingmember from the data exchange.
 10. The method of claim 1, wherein addingthe new member comprises transmitting an invitation to join the dataexchange to an email address of a user of the cloud computing service.11. A system comprising: a memory; and a processing device operativelycoupled to the memory, the processing device to: add a new member to adata exchange, wherein the data exchange comprises a set of listings;assign an account type to the new member, wherein the account type isassociated with one or more rights with respect to the set of listingssuch that the new member has a set of rights based on the account type;and modify the set of rights of the new member with respect to a listingfrom the set of listings based on a set of visibility and access rulesfor the listing, wherein the new member directs queries for data of thelisting to a reference database having a portion of the data of thelisting that is filtered based on the set of visibility and access rulesfor the listing.
 12. The system of claim 11, wherein the account type isone of a plurality of account types, the plurality of account typescomprising a consumer type, a provider type, and an exchangeadministrator type, and wherein each of the plurality of account typesis associated with one or more rights with respect to the set oflistings.
 13. The system of claim 12, wherein the account type comprisesthe consumer type, the one or more rights associated with the consumertype comprising rights to: view each listing in the set of listings,view the data of each listing in the set of listings, and access thedata of each listing in the set of listings.
 14. The system of claim 11,wherein the set of visibility and access rules for the listing comprisesrules for: filtering members of the data exchange who can view thelisting, filtering members of the data exchange who can view data of thelisting, filtering members of the data exchange who can manipulate thedata of the listing, and filtering the data of the listing thatparticular members of the data exchange can access.
 15. The system ofclaim 14, wherein to modify the set of rights of the new member withrespect to the listing, the processing device is to: restrict the newmember from viewing the listing based on the set of visibility andaccess rules for the listing.
 16. The system of claim 14, wherein tomodify the set of rights of the new member with respect to the listing,the processing device is to: filter the portion of the data of thelisting based on the set of visibility and access rules for the listing,the portion of the data of the listing comprising data the new membercan access; and grant the new member access to the portion whilerestricting the new member from access to remaining portions of the dataof the listing by including the portion of the data of the listing inthe reference database.
 17. The system of claim 16, wherein to grant thenew member access to the determined portions, the processing device isfurther to: add a reference to the reference database to an account ofthe new member.
 18. The system of claim 13, wherein the account typefurther comprises the provider type, the one or more rights associatedwith the provider type comprising rights to: create new listings in theset of listings, test sample queries on data of each of the set oflistings, set access policies for each of the set of listings, grantrequests to access each of the set of listings, and track usage of eachof the set of listings and usage of data of each of the set of listings.19. The system of claim 11, wherein the processing device is further to:remove an existing member from the data exchange; and unpublish eachlisting of the set of listings created by the existing member from thedata exchange.
 20. The system of claim 11, wherein to add the newmember, the processing device is to: transmit an invitation to join thedata exchange to an email address of a user of the cloud computingservice.
 21. A non-transitory computer-readable medium havinginstructions stored thereon which, when executed by a processing device,cause the processing device to: add a new member to a data exchange,wherein the data exchange comprises a set of listings; assign an accounttype to the new member, wherein the account type is associated with oneor more rights with respect to the set of listings such that the newmember has a set of rights based on the account type; and modify, by theprocessing device, the set of rights of the new member with respect to alisting from the set of listings based on a set of visibility and accessrules for the listing, wherein the new member directs queries for dataof the listing to a reference database having a portion of the data ofthe listing that is filtered based on the set of visibility and accessrules for the listing.
 22. The non-transitory computer-readable mediumof claim 21, wherein the account type is one of a plurality of accounttypes, the plurality of account types comprising a consumer type, aprovider type, and an exchange administrator type, and wherein each ofthe plurality of account types is associated with one or more rightswith respect to the set of listings.
 23. The non-transitorycomputer-readable medium of claim 22, wherein the account type comprisesthe consumer type, the one or more rights associated with the consumertype comprising rights to: view each listing in the set of listings,view the data of each listing in the set of listings, and access thedata of each listing in the set of listings.
 24. The non-transitorycomputer-readable medium of claim 21, wherein the set of visibility andaccess rules for the listing comprises rules for: filtering members ofthe data exchange who can view the listing, filtering members of thedata exchange who can view data of the listing, filtering members of thedata exchange who can manipulate the data of the listing, and filteringthe data of the listing that particular members of the data exchange canaccess.
 25. The non-transitory computer-readable medium of claim 24,wherein to modify the set of rights of the new member with respect tothe listing, the processing device is to: restrict the new member fromviewing the listing based on the set of visibility and access rules forthe listing.
 26. The non-transitory computer-readable medium of claim24, wherein to modify the set of rights of the new member with respectto the listing, the processing device is to: filter the portion of thedata of the listing based on the set of visibility and access rules forthe listing, the portion of the data of the listing comprising data thenew member can access; and grant the new member access to the portionwhile restricting the new member from access to remaining portions ofthe data of the listing by including the portion of the data of thelisting in the reference database.
 27. The non-transitorycomputer-readable medium of claim 26, wherein to grant the new memberaccess to the determined portions, the processing device is further to:add a reference to the reference database to an account of the newmember.
 28. The non-transitory computer-readable medium of claim 23,wherein the account type further comprises the provider type, the one ormore rights associated with the provider type comprising rights to:create new listings in the set of listings, test sample queries on dataof each of the set of listings, set access policies for each of the setof listings, grant requests to access each of the set of listings, andtrack usage of each of the set of listings and usage of data of each ofthe set of listings.
 29. The non-transitory computer-readable medium ofclaim 21, wherein the processing device is further to: remove anexisting member from the data exchange; and unpublish each listing ofthe set of listings created by the existing member from the dataexchange.
 30. The non-transitory computer-readable medium of claim 21,wherein to add the new member, the processing device is to: transmit aninvitation to join the data exchange to an email address of a user ofthe cloud computing service.